From mcdermot@eagle.aud.alcatel.com Mon Oct 31 13:16:01 1994 

Return-Path: <mcdermot@eagle.aud.alcatel.com> 

Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOx22Cz-00012MC; Mon, 31 Oct 94 13:15 CST 

Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
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Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQO711; Mon, 31 Oct 94 13:15:46 CST 

Date: Mon, 31 Oct 94 13:15:46 CST 

From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 

Message-Id: <9410311915 .AAQ0711@eagle.aud.alcatel.com> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:70] HF Modulation 


Many of my friends ask me why I hate CLOVER. I tell them that I don't 
but feel for that amount of money, hams should get more BPS for their 
buck. Hear's the reason. CLOVER uses 4 parallel tones to get 800-900 
BPS. The commercial/military modems use 39 tones to get 2400 BPS with 
the 40th tone as an unmodulated/standard modulated pilot/doppler tone. 
I believe that some where between 4 and 40 tones hams (those of you who 
are much smarter than I) can come up with a modem for HF that will be 
very robust and produce 1200-2400 (and maybe more) BPS in a BW that is 
less than the commercial/military modem. 


If the guys who will do the actual programming "max-out" the soundcard 
and produce a robust, 2400 BPS (100 baud or less) HF modem and can apply 
the the same principle to a V/UHF modem and get 9600/19.2K BPS, ham 
radio will have greatly benefited. If they can produce only 1200 BPS on 
HF and 4800 or 9600 on V/UHF, thats Ok too...just max-out the sound 
cards capability. By then, perhaps better sound cards and/or other 
devices will be on the market that will let us go higher. 


VV VV VV VV VV VV VV VV MV 


Walt@home (dba k5y£w) 


Vv 


Perhaps I'm missing a point here, or someone can correct me if 
I'm wrong ... I thought that there was a 500 hz bandwidth limit within the 
CW/RTTY segments on HF - and that one of the reasons that CLOVER is only 
4 tones (carriers) is so that it would fit within that BW limit. 


- Tom, N5EG 
From FORRERJ@frl.orst.edu Tue Nov 01 10:58:32 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
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Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAAO7397 for <hfsig@tapr.org>; Tue, 1 Nov 1994 01:36:45 
-0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 1 Nov 94 9:57:14 PST8PDT 


Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 1 Nov 94 9:57:05 PST8PDT 
From: "Johan Forrer 

FL" <FORRERJ@£rl.orst.edu> 

Organization: Forest Research Lab. Oregon State 

To: hfsig@tapr.org 


Date: Tue, 1 Nov 1994 09:56:58 PST8PDT 
Subject: Re: [HFSIG:72] Re: HF Modulation 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <6B8BA2E5D76@frl.orst.edu> 
Hi Tom, 


Re: 500 Hz BW limitation - our digital activies on HF are regulated by 
Part 97 of the FCC regulations: it says that we can use up to 300 baud or 
1000 Hz shift. 


The 500 Hz BW issue has been brought up recently by parts of the digital 
community that has actually gone so far as to file petition requesting 

such BW for for semi-automatic operations (mainly APlink usage). Except for 
the Clover modulation scheme, none of the xpresently availablex equipment 
is capable of staying within 500 Hz. This is due to the "fuzzy" definition 
of how folks measure emitted BW. If you do like the Clover folks and 
specify BW at say 50 dB down from the main lobe, then just about everyone 
else uses in excess of 800 Hz. So, asking for 500 Hz BW right now with what 
is on the market right now, Clover is the only one that will comply for 
APlink usage. Does folks realize what this petition means? 


Thanks for bringing up this point - hopefully we will show that with the 
right kind of technology, our present BW allocation can go a long way 
towards high speed HF digital - there is no need for additional regulations. 


73's 


Johan 
From jbloom@arrl.org Tue Nov 01 12:17:06 1994 
Return-Path: <jbloom@arrl.org> 
Received: from uu7.psi.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOr2N1V-QOQOOhUC; Tue, 1 Nov 94 12:17 CST 
Received: from mgate.arrl.org by uu7.psi.com (5.65b/4.0.071791-PSI/PSINet) via 
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(Smail3.1.28.1 #6) id mOr2Nj£-O000B9iC; Tue, 1 Nov 94 13:15 EST 
Received: by arrl.org with Microsoft Mail 
id <2EB68625@arrl.org>; Tue, 01 Nov 94 13:17:09 EST 
From: "Bloom, Jon, KE3Z" <jbloom@arrl.org> 
To: hfsig <hfsig@tapr.org> 
Subject: RE: [HFSIG:73] Re: HF Modulation 
Date: Tue, 01 Nov 94 13:15:00 EST 
Message-Id: <2EB68625@arrl.org> 
Encoding: 35 TEXT 


X-Mailer: Microsoft Mail V3.0 


>The 500 Hz BW issue has been brought up recently by parts of the digital 
>community that has actually gone so far as to file petition requesting 
>such BW for for semi-automatic operations (mainly APlink usage). Except for 


>the Clover modulation scheme, none of the xpresently availablex equipment 
>is capable of staying within 500 Hz. This is due to the "fuzzy" definition 
>of how folks measure emitted BW. If you do like the Clover folks and 
>specify BW at say 50 dB down from the main lobe, then just about everyone 
>else uses in excess of 800 Hz. So, asking for 500 Hz BW right now with what 


>is on the market right now, Clover is the only one that will comply for 
>APlink usage. Does folks realize what this petition means? 


The specification of occupied bandwidth is in Sec 2.202 of FCC Rules and 
Regulations (Appendix 10 in ARRL's FCC Rule Book). It is set by the points 
in the spectrum where the sum of the power at frequencies above and below 
those points is 0.5% of the total power. (Interestingly, there is a 
qualification of this rule for multi-channel frequency division systems, 
which may have difficulty meeting such a definition.) In any case, 170-Hz 
shift, 100-baud transmissions (AMTOR or RTTY) with proper key shaping fall 
within a 500-Hz bandwidth by the above definition. The 500-Hz bandwidth 
limitation does *not* rule out the use of modes other than Clover! 


That said, the FCC's definition of bandwidth is probably not the one we want 
to key on. The reason Clover strives to maintain almost all of its energy 
within a 500-Hz bandwidth is not for legal requirements, rather it's because 
doing so means you can actually use 500-Hz channelization. Try running a 
mediocre AMTOR link when there's another AMTOR station 500-Hz away that is 
40 dB above the station you're trying to copy. That adjacent-channel station 
may be "occupying" a 500-Hz bandwidth, but you'll still find your copy 
corrupted by his "insignificant" sidebands only 30 dB or so down from his 
carrier. 


-- Jon, KE3Z 

From FORRERJ@frl.orst.edu Tue Nov 01 13:37:36 1994 

Return-Path: <FORRERJ@frl.orst.edu> 

Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOr2P1S-0001KzC; Tue, 1 Nov 94 13:37 CST 

Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
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-0800 

Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 1 Nov 94 11:37:17 PST8PDT 

Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 1 Nov 94 11:37:04 

PST8PDT 

From: "Johan Forrer 

FL" <FORRERJ@frl.orst.edu> 

Organization: Forest Research Lab. Oregon State 

To: HFSIG@tapr.org 

Date: Tue, 1 Nov 1994 11:36:56 PST8PDT 


Subject: HF Channel simulator 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 
Message-ID: <6BB64D6637A@frl.orst.edu> 


Greetings, 


For those interested in the channel simulator, do yourself a favour and 
also obtain the Watterson et al. paper: 


Clack C. Watterson, John R. Jurosheck, and William D. Bensema: 
"Experimental Confirmation of an HF Channel Model". IEEE Trans. on Comm. 
Tech. Vol COM-18(6) December 1970. 


It appears quite doable - perhaps we should form a working group of those 
that wish to actively participate in coding this model? Please e-mail me 
directly. Does this sound reasonable? We will post our progress (if any). 


73's 


Johan 
From FORRERJ@frl.orst.edu Tue Nov 08 11:47:55 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
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(8.6.9/8.6.9) with SMTP id CAA10584 for <HFSIG@tapr.org>; Tue, 8 Nov 1994 02:26:48 
-0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 8 Nov 94 9:47:32 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 8 Nov 94 9:47:30 PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Tue, 8 Nov 1994 09:47:30 PST8PDT 
Subject: HF Modulation 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <761961E4752@frl.orst.edu> 
Hi Folks, 
Quiet on the homefront? 


A few general comments: I have suggested some reading materials - 
If you have do not have access to these, perhaps I can help make 
photocopies - please e-mail me directly. These papers are quite 
old, though very appropriate. Unfortunately they also are quite 
mathematically inclined - however, don't be intimidated by a bit 
of algebra. If you are not interested in all the gory details, 
just make sure you understand the premise and note the 


conclusions. Some things take a while to sink in and as one 
develop your grasp of the subject, it becomes clearer later. 


The insight that these papers attempt to provide is: given some 

model of the "channel", how does different modulation schemes 

stack up? Typically various forms of OOK (on-off keying), FSK, 

and PSK, are considered against white (additive Gaussian white) 

noise - where it is shown that: for the same amount of emitted 

energy, phase modulation schemes have slightly lower error 

rates. Now keep in mind that some rather important assumptions 

are made, i.e. that we have the RX and TX in perfect sync as far 

as carrier phase and symbol sync is concerned. Well, what happens 

if that is not the case and what if the channel model includes phase jitter? 
We see that performance drops rather dramatically. This is where the issue 
of robustness comes in and where we see that noncoherent FSK actually does 
very well - it requires little or no assumptions! However, just keep those 
theoretical rankings in mind as the limits of performance under 

ideal conditions. 


Well, then why don't we just go ahead and use noncoherent FSK? 

Lets say we are aiming for 1200 bps (uncoded). 

Theoretically, this would require a minimum of 1200 Hz shift, and need at 
least an additional 1200 Hz to accommodate the modulation 

envelope - total about 2400 Hz. Two major problems: that's a lot 

of bandwidth for HF, second, such short bit times would be a 

disaster on HF with multipath and the other kinds of channel 

anomalies. OK - so what else can we do? We have to make a 

tradeoff: lower robustness for more bandwidth efficiency. That is 

why some of those papers looked at those complex modulated schemes, i.e. 
QAM etc.. and their performance under non-ideal conditions. The Foschini 
paper surprisingly shows that QAM does better than expected - 

which is great news. 


The other papers is about carrier and data recovery using phase 
lock loops - more about this later. 


One last note: the 2-3 dB loss in performance associated with a 
bandwidth-efficient modulation scheme, may be offset with coding gain 
achieved by coding theory, i.e. trellis modulation/viterbi demodulation 
etc. This sophistication, unfortunately, adds greater complexity to the 
implementation. The DSP/host algorithms are necessarily going to be closely 
coupled and this alone hints that an involved system is in your 

future. 


A bit of progress with the PSK modem - the modulator is working 
nicely and soon I'll be testing with two sound cards back-to- 
back. This setup, however, is very experimental and is, for me at 
least, a way of learning how all these intricate algorithms work 
together. 


I have collected and studied some further materials on the channel 
simulator, enough to see that it is quite doable. More about that later. 


I would like to hear any further thoughts or suggestions from your side. 
Please let us hear from you. 


73's 


Johan 
From FORRERJ@frl.orst.edu Tue Nov 08 12:17:07 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOr4v60-000162C; Tue, 8 Nov 94 12:17 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
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-0800 
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Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 8 Nov 94 10:16:16 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERIJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Tue, 8 Nov 1994 10:16:12 PST8PDT 
Subject: SOUNDWAVE TOOLS 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <76210DD4A6A@fr1l.orst.edu> 


>Hi Johan, 

> 

>I just received my Soundwave card yesterday. It sure is fun having a new 
>toy! You once mentioned (I think) that there is a freeware assembler for 
>the DSP floating around out there. Can you tell me where? Also, is there 
>any board-level technical documentation (i.e. block diagram, memory map, 
>etc.) available to developers? I can get data books on the individual 
>chips from their respective vendors, but it would be nice to know how they 
>go together! 

> 

>Maybe you should post your reply to the net. 

> 

73S 


OK - now the fun really starts! 


First get hold of the August 1994 QEX. I have described the chip set, 
memory layout, and mayor PC-DSP programming issues in some detail in 
that article. 


You also xmust*x get the AD1848 data sheet for sure, and the 21xx user's 
guide for sure. That will help you with the 2115's architecture and 


programmer's model. 


The most recent PD toolkit for the sound card is available from ftp.ucsd.edu 
in /hamradio/packet/tcpip/incoming/psatool1.zip, also at ftp.cs.buffalo. 

You will also find some further example applications code for the QEX 
article(s) there too. Also check out my port of the W9GR DSP for the 

sound card - I recently uploaded that. 


I wonder if you have obtained HB9IJNX's 9600 baud G3RUH modem for the 
sound card? If so, perhaps you could make that available too? That may be 
and interesting application to explore. 


I would also suggest browsing Analog Devices ftp site: ftp.analog.com 
(137.71.23.11) for all sorts of useful bits of hardware/software 
information and code examples. 


Keep in mind that there are xrealx ADI software tools available - I 
recently got their assembler/linker/simulator and C-compiler at very 
reasonable cost during a "special" offer deal. 


This will keep you busy for a while, but let me know if you need further 
assistance. 


73's 


Johan 

From mcdermot@eagle.aud.alcatel.com Tue Nov 08 15:06:22 1994 

Return-Path: <mcdermot@eagle.aud.alcatel.com> 

Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp 
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Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
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Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ6303; Tue, 8 Nov 94 15:05:56 CST 

Date: Tue, 8 Nov 94 15:05:56 CST 

From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 

Message-Id: <9411082105.AA06303@eagle.aud.alcatel.com> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:76] HF Modulation 


Hi Folks, 
Quiet on the homefront? 


A few general comments: I have suggested some reading materials - 
If you have do not have access to these, perhaps I can help make 
photocopies - please e-mail me directly. These papers are quite 
old, though very appropriate. Unfortunately they also are quite 
mathematically inclined - however, don't be intimidated by a bit 
of algebra. If you are not interested in all the gory details, 
just make sure you understand the premise and note the 
conclusions. Some things take a while to sink in and as one 
develop your grasp of the subject, it becomes clearer later. 


VV VV VV VV VV VV OV 


> I would like to hear any further thoughts or suggestions from your side. 
> Please let us hear from you. 

> 

> 73's 

> 

> Johan 

> 


Johan, I acquired a copy of "Experimental Confirmation of an HF 
Channel Model" IEEE ComTech, COM-18 No. 6. The channel model proposed seems 
straight-forward, however the derivation of the baseband channel modulation 
functions, Gi(t) is anything but straight-forward, and certainly a little 
bit beyond algebra. 


Mapping of the parameters from tables I and II into deterministic 
formulas has so far eluded me. Have you looked into this? My guess would be 
to choose random processes with gaussian distributions to fit the observed 
data. However, I see the problem as one of mapping random PHASE of G(t) 
into a gaussian-shaped FREQUENCY shift of the signal, a bit beyond my 
mathematical background at present. Do you know of a simple algorithm that 
generates gaussian-distributed random numbers? 


Additionally, the author states that the fading of each individual 
propagation component is represented by a Rayleigh distribution. I think the 
formula for that is fairly tractable. I would assume that a random-number 
generator that creates a Rayleigh distribution applied to the magnitude of 
each Gi(t) would be used here. I found a simple formula from some microwave 
radio stuff done here about 10 years ago (where a Rayleigh path is the 
standard assumption) but it is not clear what the coefficients should be 
after looking at Tables I and II. 


The two data points were taken at 9.26 Mhz, and 5.86 Mhz. Would 
the data points taken from a higher frequency (14, 21, 28 Mhz) be 
significantly different (with a potentially longer path, one might think so). 


The article is definitely interesting, but after two complete read 
throughs, it will still require significant study to grasp. 


- Tom, N5EG 

From Glen_Worstell@notes.seagate.com Tue Nov 08 17:47:24 1994 
Return-Path: <seagate!notes.seagate.com!Glen_Worstell@netcom. com> 
Received: from netcomsv.netcom.com by dptspd.sat.datapoint.com with smtp 
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Received: by notes.seagate.com (UUPC/extended 1.11q); 

Tue, 08 Nov 1994 16:19:03 EST 

Date: Tue Nov 08 16:19:03 1994 
From: "Glen Worstell" <Glen_Worstell@notes.seagate.com> 
Sender: Gateway <gateway@notes.seagate.com> 


Message-ID: <2ebfeb48.seagate@notes.seagate.com> 
Organization: Seagate Technology 

Reply-To: "Glen Worstell" <Glen_Worstell@notes.seagate.com> 
To: hfsig@tapr.org 

Subject: Re: [HFSIG:78] Re: HF Modulation 


> Do you know of a simple algorithm that generates 
gaussian-distributed random numbers? 


Two answers: 
1) use the "randn" function in Matlab. 
2) From "Communication Formulas and Algorithms", C. Rorabaugh: 


a) Generate a psuedorandom floating point number U1 greater 
than 0 and <= 1.0 

b) Generate another one, U2. 

c) Gt1=cos(U2)*sqrt(-2*1n(U1)*sigmaxsigma) 

d) G2=sin(U2)*sqrt(-2*1n(U1)*sigmaxsigma) 


G1 and G2 will be independent zero-mean gaussian "random 
numbers" with standard deviation of sigma. 


The book gives another method which is a bit faster as it 
does not use trig functions. 


Important: you must have a good random number generator 

routine to start with. some unix systems have 16 bit generators 
which are not very good. Also, for this sort of work the gaussian 
generator must have a good "crest factor". That is, the percent 
of numbers exceeding, say, 6 sigma must be in the ballpark of 

the predicted amount. This will not happen if the quality of the 
random number generator is not good (for example, not enuf 

bits). 


I used this method in a disk channel simulator, with good 
results. Disk drives are a lot like communication channels! 


Cheers, 
Glen Worstell, KGOT 


Glen Worstell -- Glen_Worstell@notes.seagate.com 
Seagate Technology = 920 Disc Drive - Scotts Valley, CA 95066 USA 
Main Phone 408-438-6550 = Email Problems postmaster@notes.seagate.com 


Technical Support: BBS 408-438-8771 Fax 408-438-8137 Voice 408-438-8222 


iHHF OGATE Version 8 message trace and attachment information: 
dHHE MsgFileName: m:\mgate\outbound\516.MSG 


iHHF Org Date: 11-08-94 03:20:47 PM 
JHHF From: Glen Worstell@SEAGATE 
JHHE To: hfsig @ tapr.org @ INTERNET 


dHHF Subject: Re: [HFSIG:78] Re: HF Modulation 


dHHE Attachments: none 
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Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOr50Zt-O0001iFC; Tue, 8 Nov 94 18:07 CST 
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PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Tue, 8 Nov 1994 16:07:13 PST8PDT 
Subject: Re: [HFSIG:78] Re: HF Modulation 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <767EBOE2676@frl.orst.edu> 


>> Hi Folks, 

>> 

>> Quiet on the homefront? 

>> 

>> A few general comments: I have suggested some reading materials - 
>> If you have do not have access to these, perhaps I can help make 
>> photocopies - please e-mail me directly. These papers are quite 
>> old, though very appropriate. Unfortunately they also are quite 
>> mathematically inclined - however, don't be intimidated by a bit 
>> of algebra. If you are not interested in all the gory details, 
>> just make sure you understand the premise and note the 

>> conclusions. Some things take a while to sink in and as one 

>> develop your grasp of the subject, it becomes clearer later. 


>> I would like to hear any further thoughts or suggestions from your side. 
>> Please let us hear from you. 


>> 
>> 73's 

>> 

>>Johan 

>> 

> Johan, I acquired a copy of "Experimental Confirmation of an HF 


>Channel Model" IEEE ComTech, COM-18 No. 6. The channel model proposed 
>seems straight-forward, however the derivation of the baseband channel 
>modulation functions, Gi(t) is anything but straight-forward, and certainly 
>a little bit beyond algebra. 


Outstanding Tom! ..... agree that nothing about this is that simple - but 
folks should also not feel intimidated by scolarly papers. I'ma 

mediocre mathematician at best with self-taught interests in DSP and COMM 
theory - programming is what I like best. 


Lets explore your questions and perhaps we can unravel this thing 
together ..... 


>>Mapping of the parameters from tables I and II into deterministic 
>formulas has so far eluded me. Have you looked into this? My guess would 
>be to choose random processes with gaussian distributions to fit the 
>observed data. However, I see the problem as one of mapping random PHASE 
>of G(t) into a gaussian-shaped FREQUENCY shift of the signal, a bit beyond 
> my mathematical background at present. Do you know of a simple algorithm 
>that generates gaussian-distributed random numbers? 


I think you have a good grasp of what is required. What might help 

further now is to get CCIR Report 549-2 - look at p.60-62 for a fuller 
description of the Gaussian-scatter model and formulae. Tables I and II of 
the Watterson paper is very complete and you probably don't want to try and 
emulate that in its entirety. If you further obtain CCIR 520- 1, they 

list all the parameters of interest for "Good", "Moderate", "Poor", and 
"Flutter fading" that may be put to good use in the model. 


About the random Gaussian number generator, lets keep in 
mind that the baseband signal is complex, thus you need to generate a 
complex random number too, i.e.: 


WGN_real = std * sqrt (-2*1n(ran1)*xcos(2x*pixran2) ) 
WGN AMA Gs SP slot don Pee ds Pee tee Dik ST esos eth aeant ces 


where: std is the std. dev. of GN, 
rani, ran2 is uniformly distributed between 0,1 


Then you have to think a little about how to balance the summation node, 
i.e. the amount of power that each tap is going to contribute. 


Also think a bit about what you are going to do about the different 
sample rates involved at each tap, i.e. they will be somewhat different 
thus you would have to include interpolating filters before mixing in the 
doppler signal. OK? 


> 

> Additionally, the author states that the fading of each individual 
>propagation component is represented by a Rayleigh distribution. I think 
>the formula for that is fairly tractable. I would assume that a random- 


Yes, that is described in the references of CCIR 549-2 and also in some 
detail on p.62 of 549-2. 


> The two data points were taken at 9.26 Mhz, and 5.86 Mhz. Would 
>the data points taken from a higher frequency (14, 21, 28 Mhz) be 
>significantly different (with a potentially longer path, one might think 
>so). 

> 


Certainly - different frequencies will behave differently - from 
what I have read on this subject, multipath, is strongly dependant 
on the MUF. 


> The article is definitely interesting, but after two complete read 
>throughs, it will still require significant study to grasp. 

> 

> - Tom, N5EG 


Appreciate your feedback. I would not have known anything on this topic 
were it not for generous help from others (I still am struggling with this 
too). 


Keep us posted on your progress. 


Johan, KC7WW 

From esilbaug@afit.af.mil Tue Nov 08 20:06:24 1994 

Return-Path: <esilbaug@afit.af.mil> 

Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp 

(Smail3.1.28.1 #3) id mOr52QW-00011YC; Tue, 8 Nov 94 20:06 CST 

Received: from owl.afit.af.mil by stealth.afit.af£.mil with SMTP id AA11090 
(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Tue, 8 Nov 1994 21:06:15 -0500 

Date: Tue, 8 Nov 1994 21:06:15 -0500 

From: Eric E Silbaugh <esilbaug@afit.af.mil> 

Message-Id: <199411090206.AA11090@stealth.afit.af.mil> 

To: hfsig@tapr.org 

Subject: RE: HF Channel Simulator 

Cc: esilbaug@afit.af.mil 


Those of you who have been discussing HF channel simulation may 
be interested in the following paper. I ran across it while doing 
research on an unrelated topic. 


L. Ehrman, L.B. Bates, J.F. Eschile, J.M. Kates, "Realtime 
Software Simulation of the HF Radio Channel" IEEE Trans. on 
Communications, August 1982, p.1809 


It contains an overview of the theoretical HF channel model and 
details on how it was implemented on a signal processor. They 
used special purpose hardware but today's DSP chips should be up 


to the task. 


For those of you interested in how various modulation methods 
hold up under interference, check out this paper. 


0.A.H. Shabsigh, "On the Effects of CW Interference on MSK 
Signal Reception" IEEE Trans. on Communications, August 
1982, p.1925 


Wouldn't want our fancy new demodulator to crumble when some lid 
starts doing 5 WPM on top of our signal would we. 


I have enjoyed lurking on this SIG for a few weeks. Lots of 
good ideas floating around (now, if we could only catch them). 
By the way, I'm currently pursuing an MSEE in communications 

and radar systems. I got into amateur radio to put some of this 
theory into practice. Later! 


Eric 


ie 2 ee Eric E. Silbaugh 
3 goes esilbaug@afit.af.mil 


: se All standard, non-standard, and 
SE ESS AS Ss MIL-STD disclaimers apply 
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Received: from smtp-gw.spawar.navy.mil by opal.spawar.navy.mil (4.1/SMI-4.1) 
id AA15566; Wed, 9 Nov 94 00:52:20 EST 
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Date: Wed, 09 Nov 94 00:51:46 EST 
From: Administrator_at_SPAWAR-MC4@smtp-gw.spawar.navy.mil 
Encoding: 111 Text 
Message-Id: <9410097843 .AA784371227@smtp- gw.spawar.navy.mil> 
To: hfsig@tapr.org 
Subject: Message not deliverable 


>> Hi Folks, 

>> 

>> Quiet on the homefront? 

>> 

>> A few general comments: I have suggested some reading materials - 
>> If you have do not have access to these, perhaps I can help make 
>> photocopies - please e-mail me directly. These papers are quite 
>> old, though very appropriate. Unfortunately they also are quite 
>> mathematically inclined - however, don't be intimidated by a bit 
>> of algebra. If you are not interested in all the gory details, 
>> just make sure you understand the premise and note the 

>> conclusions. Some things take a while to sink in and as one 


>> develop your grasp of the subject, it becomes clearer later. 


>> I would like to hear any further thoughts or suggestions from your side. 
>> Please let us hear from you. 


>> 
>> 73's 

>> 

>>Johan 

>> 

> Johan, I acquired a copy of "Experimental Confirmation of an HF 


>Channel Model" IEEE ComTech, COM-18 No. 6. The channel model proposed 
>seems straight-forward, however the derivation of the baseband channel 
>modulation functions, Gi(t) is anything but straight-forward, and certainly 
>a little bit beyond algebra. 


Outstanding Tom! ..... agree that nothing about this is that simple - but 
folks should also not feel intimidated by scolarly papers. I'ma 

mediocre mathematician at best with self-taught interests in DSP and COMM 
theory - programming is what I like best. 


Lets explore your questions and perhaps we can unravel this thing 
together ..... 


>>Mapping of the parameters from tables I and II into deterministic 
>formulas has so far eluded me. Have you looked into this? My guess would 
>be to choose random processes with gaussian distributions to fit the 
>observed data. However, I see the problem as one of mapping random PHASE 
>of G(t) into a gaussian-shaped FREQUENCY shift of the signal, a bit beyond 
> my mathematical background at present. Do you know of a simple algorithm 
>that generates gaussian-distributed random numbers? 


I think you have a good grasp of what is required. What might help 

further now is to get CCIR Report 549-2 - look at p.60-62 for a fuller 
description of the Gaussian-scatter model and formulae. Tables I and II of 
the Watterson paper is very complete and you probably don't want to try and 
emulate that in its entirety. If you further obtain CCIR 520- 1, they 

list all the parameters of interest for "Good", "Moderate", "Poor", and 
"Flutter fading" that may be put to good use in the model. 


About the random Gaussian number generator, lets keep in 
mind that the baseband signal is complex, thus you need to generate a 


complex random number too, i.e.: 


WGN_real = std * sqrt (-2*1n(ran1)*xcos(2*pixran2) ) 
WGN mag = see wea aka eer eile as ae SIMs as Gavoweee 4 


where: std is the std. dev. of GN, 


rani, ran2 is uniformly distributed between 0,1 


Then you have to think a little about how to balance the summation node, 
i.e. the amount of power that each tap is going to contribute. 


Also think a bit about what you are going to do about the different 
sample rates involved at each tap, i.e. they will be somewhat different 
thus you would have to include interpolating filters before mixing in the 
doppler signal. OK? 


> 

> Additionally, the author states that the fading of each individual 
>propagation component is represented by a Rayleigh distribution. I think 
>the formula for that is fairly tractable. I would assume that a random- 


Yes, that is described in the references of CCIR 549-2 and also in some 
detail on p.62 of 549-2. 


> The two data points were taken at 9.26 Mhz, and 5.86 Mhz. Would 
>the data points taken from a higher frequency (14, 21, 28 Mhz) be 
>significantly different (with a potentially longer path, one might think 
>so). 

> 


Certainly - different frequencies will behave differently - from 
what I have read on this subject, multipath, is strongly dependant 
on the MUF. 


> The article is definitely interesting, but after two complete read 
>throughs, it will still require significant study to grasp. 

> 

> - Tom, N5EG 


Appreciate your feedback. I would not have known anything on this topic 
were it not for generous help from others (I still am struggling with this 
too). 


Keep us posted on your progress. 
Johan, KC7WW 
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>> Hi Folks, 

>> 

>> Quiet on the homefront? 

>> 

>> A few general comments: I have suggested some reading materials - 
>> If you have do not have access to these, perhaps I can help make 
>> photocopies - please e-mail me directly. These papers are quite 
>> old, though very appropriate. Unfortunately they also are quite 
>> mathematically inclined - however, don't be intimidated by a bit 
>> of algebra. If you are not interested in all the gory details, 
>> just make sure you understand the premise and note the 

>> conclusions. Some things take a while to sink in and as one 

>> develop your grasp of the subject, it becomes clearer later. 


>> I would like to hear any further thoughts or suggestions from your side. 
>> Please let us hear from you. 


>> 

>> 73's 

>> 

>>Johan 

>> 

> Johan, I acquired a copy of "Experimental Confirmation of an HF 


>Channel Model" IEEE ComTech, COM-18 No. 6. The channel model proposed 
>seems straight-forward, however the derivation of the baseband channel 
>modulation functions, Gi(t) is anything but straight-forward, and certainly 
>a little bit beyond algebra. 


Outstanding Tom! ..... agree that nothing about this is that simple - but 
folks should also not feel intimidated by scolarly papers. I'ma 

mediocre mathematician at best with self-taught interests in DSP and COMM 
theory - programming is what I like best. 


Lets explore your questions and perhaps we can unravel this thing 
together ..... 


>>Mapping of the parameters from tables I and II into deterministic 
>formulas has so far eluded me. Have you looked into this? My guess would 
>be to choose random processes with gaussian distributions to fit the 
>observed data. However, I see the problem as one of mapping random PHASE 


>of G(t) into a gaussian-shaped FREQUENCY shift of the signal, a bit beyond 
> my mathematical background at present. Do you know of a simple algorithm 
>that generates gaussian-distributed random numbers? 


I think you have a good grasp of what is required. What might help 

further now is to get CCIR Report 549-2 - look at p.60-62 for a fuller 
description of the Gaussian-scatter model and formulae. Tables I and II of 
the Watterson paper is very complete and you probably don't want to try and 
emulate that in its entirety. If you further obtain CCIR 520- 1, they 

list all the parameters of interest for "Good", "Moderate", "Poor", and 
"Flutter fading" that may be put to good use in the model. 


About the random Gaussian number generator, lets keep in 
mind that the baseband signal is complex, thus you need to generate a 
complex random number too, i.e.: 


WGN_real = std * sqrt (-2*1n(ran1)*xcos(2*pixran2) ) 
WGN IMAG! = od gece eee ee SEN dead deg ee 


where: std is the std. dev. of GN, 
rani, ran2 is uniformly distributed between 0,1 


Then you have to think a little about how to balance the summation node, 
i.e. the amount of power that each tap is going to contribute. 


Also think a bit about what you are going to do about the different 
sample rates involved at each tap, i.e. they will be somewhat different 
thus you would have to include interpolating filters before mixing in the 
doppler signal. OK? 


> 

> Additionally, the author states that the fading of each individual 
>propagation component is represented by a Rayleigh distribution. I think 
>the formula for that is fairly tractable. I would assume that a random- 


Yes, that is described in the references of CCIR 549-2 and also in some 
detail on p.62 of 549-2. 


> The two data points were taken at 9.26 Mhz, and 5.86 Mhz. Would 
>the data points taken from a higher frequency (14, 21, 28 Mhz) be 
>significantly different (with a potentially longer path, one might think 
>so). 

> 


Certainly - different frequencies will behave differently - from 
what I have read on this subject, multipath, is strongly dependant 
on the MUF. 


> The article is definitely interesting, but after two complete read 
>throughs, it will still require significant study to grasp. 

> 

> - Tom, N5EG 


Appreciate your feedback. I would not have known anything on this topic 
were it not for generous help from others (I still am struggling with this 
too). 


Keep us posted on your progress. 


Johan, KC7WW 
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Date: Wed, 09 Nov 94 06:10:30 EST 

From: Administrator_at_SPAWAR-MC4@smtp-gw.spawar.navy.mil 

Encoding: 113 Text 

Message-Id: <9410097843 .AA784390258@smtp- gw. spawar.navy.mil> 

To: hfsig@tapr.org 

Subject: Message not deliverable 


>> Hi Folks, 

>> 

>> Quiet on the homefront? 

>> 

>> A few general comments: I have suggested some reading materials - 
>> If you have do not have access to these, perhaps I can help make 
>> photocopies - please e-mail me directly. These papers are quite 
>> old, though very appropriate. Unfortunately they also are quite 
>> mathematically inclined - however, don't be intimidated by a bit 
>> of algebra. If you are not interested in all the gory details, 
>> just make sure you understand the premise and note the 

>> conclusions. Some things take a while to sink in and as one 

>> develop your grasp of the subject, it becomes clearer later. 


>> I would like to hear any further thoughts or suggestions from your side. 
>> Please let us hear from you. 


>> 73's 
>> 
>>Johan 


>> 


> Johan, I acquired a copy of "Experimental Confirmation of an HF 
>Channel Model" IEEE ComTech, COM-18 No. 6. The channel model proposed 
>seems straight-forward, however the derivation of the baseband channel 
>modulation functions, Gi(t) is anything but straight-forward, and certainly 
>a little bit beyond algebra. 


Outstanding Tom! ..... agree that nothing about this is that simple - but 
folks should also not feel intimidated by scolarly papers. I'ma 

mediocre mathematician at best with self-taught interests in DSP and COMM 
theory - programming is what I like best. 


Lets explore your questions and perhaps we can unravel this thing 
together ..... 


>>Mapping of the parameters from tables I and II into deterministic 
>formulas has so far eluded me. Have you looked into this? My guess would 
>be to choose random processes with gaussian distributions to fit the 
>observed data. However, I see the problem as one of mapping random PHASE 
>of G(t) into a gaussian-shaped FREQUENCY shift of the signal, a bit beyond 
> my mathematical background at present. Do you know of a simple algorithm 
>that generates gaussian-distributed random numbers? 


I think you have a good grasp of what is required. What might help 

further now is to get CCIR Report 549-2 - look at p.60-62 for a fuller 
description of the Gaussian-scatter model and formulae. Tables I and II of 
the Watterson paper is very complete and you probably don't want to try and 
emulate that in its entirety. If you further obtain CCIR 520- 1, they 

list all the parameters of interest for "Good", "Moderate", "Poor", and 
"Flutter fading" that may be put to good use in the model. 


About the random Gaussian number generator, lets keep in 
mind that the baseband signal is complex, thus you need to generate a 
complex random number too, i.e.: 


WGN_real = std * sqrt (-2x*1n(ran1)*xcos(2x*pixran2) ) 
WGN IMAS) = ed aoe eee eed aes SUN itcteake kis. § 


where: std is the std. dev. of GN, 
rani, ran2 is uniformly distributed between 0,1 


Then you have to think a little about how to balance the summation node, 
i.e. the amount of power that each tap is going to contribute. 


Also think a bit about what you are going to do about the different 
sample rates involved at each tap, i.e. they will be somewhat different 
thus you would have to include interpolating filters before mixing in the 
doppler signal. OK? 


> 

> Additionally, the author states that the fading of each individual 
>propagation component is represented by a Rayleigh distribution. I think 
>the formula for that is fairly tractable. I would assume that a random- 


Yes, that is described in the references of CCIR 549-2 and also in some 
detail on p.62 of 549-2. 


> The two data points were taken at 9.26 Mhz, and 5.86 Mhz. Would 
>the data points taken from a higher frequency (14, 21, 28 Mhz) be 
>significantly different (with a potentially longer path, one might think 
>so). 

> 


Certainly - different frequencies will behave differently - from 
what I have read on this subject, multipath, is strongly dependant 
on the MUF. 


> The article is definitely interesting, but after two complete read 
>throughs, it will still require significant study to grasp. 

> 

> - Tom, N5EG 


Appreciate your feedback. I would not have known anything on this topic 
were it not for generous help from others (I still am struggling with this 
too). 


Keep us posted on your progress. 


Johan, KC7WW 


From mcdermot@eagle.aud.alcatel.com Wed Nov 09 07:54:13 1994 

Return-Path: <mcdermot@eagle.aud.alcatel.com> 
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(Smail3.1.28.1 #3) id mOr5DTT-OOOOLAC; Wed, 9 Nov 94 07:54 CST 
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Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
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Date: Wed, 9 Nov 94 07:53:43 CST 

From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 

Message-Id: <9411091353 .AA06918@eagle.aud.alcatel.com> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:80] Re: HF Modulation 


> About the random Gaussian number generator, lets keep in 
> mind that the baseband signal is complex, thus you need to generate a 
> complex random number too, i.e.: 

> 

> WGN_real = std * sqrt (-2*1n(ran1)*cos(2x*pixran2) ) 

> WGN mad: Sg doe deve hand Ya Sata weekend wen SU nd Foe MEE 

> 

> where: std is the std. dev. of GN, 

> rani, ran2 is uniformly distributed between 0,1 

> 

> Johan, KC7WW 

> 


Johan: the author states that the phase is uniformly distributed. 
>From this one would guess that the uniform phase results in gaussian 
frequency, but I have a hard time believing this, actually (doesn't seem 
intuitive). Given the Rayleigh amplitude distribution, I was assuming 
that the two components of Gi(t) would be magnitude and phase, with the 
above two (non-complex) random distributions. Then of course we would do 
polar-to-rectangular converstion in order to multiply Gi(t) by the delayed 
Signal. My guess is that the tapped delay line only contains the real part 
of the input signal, but after multiplication by Gi(t), of course it is then 
complex. 


Those of you who have been discussing HF channel simulation may 
be interested in the following paper. I ran across it while doing 
research on an unrelated topic. 


L. Ehrman, L.B. Bates, J.F. Eschile, J.M. Kates, "Realtime 
Software Simulation of the HF Radio Channel" IEEE Trans. on 
Communications, August 1982, p.1809 


It contains an overview of the theoretical HF channel model and 
details on how it was implemented on a signal processor. They 
used special purpose hardware but today's DSP chips should be up 
to the task. 


VVVV VV VV VV VV VV 


Eric 


Thanks for the reference, Eric! Nothing like seeing a real 
implementation. 


- Tom, N5EG 

From jbloom@arrl.org Wed Nov 09 09:28:54 1994 
Return-Path: <jbloom@arrl.org> 
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Received: from mgate.arrl.org by uu7.psi.com (5.65b/4.0.071791-PSI/PSINet) via 
SMTP; 
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Received: from arrl.org by mgate.arrl.org with smtp 
(Smail3.1.28.1 #6) id mOr5Etn-O00B9jC; Wed, 9 Nov 94 10:25 EST 
Received: by arrl.org with Microsoft Mail 
id <2ECOEAFF@arrl.org>; Wed, 09 Nov 94 10:30:07 EST 
From: "Bloom, Jon, KE3Z" <jbloom@arrl.org> 
To: hfsig <hfsig@tapr.org> 
Subject: RE: [HFSIG:85] Re: HF Modulation 
Date: Wed, 09 Nov 94 10:30:00 EST 
Message-Id: <2ECOEAFF@arrl.org> 
Encoding: 27 TEXT 
X-Mailer: Microsoft Mail V3.0 


I just acquired a copy of "Simulation of Communication Systems," by Michel 
C. Jeruchim, Philip Balaban and K. Sam Shanmugan. (1992, Plenum Press, New 
York. ISBN 0-306-43989-1.) If you can find a copy of this (I bought mine, to 
the tune of $110), you'll find more than you ever wanted to know about this 
subject! I've yet to find time to delve into it deeply, but it looks like it 
covers the subject in detail, including providing the mathematical 
background. 


>> WGN_real = std * sqrt (-2*«ln(ran1)*cos(2*pixran2) ) 


SP WGN TAMAS = aise acer aie ee oa when SAN ekki we ahnare ey 

>> 

>> where: std is the std. dev. of GN, 

>> rani, ran2 is uniformly distributed between 0,1 


Should the trig functions be inside the square root as shown? In the book 
referenced above, (in section 3.11, "Computer Generation of Random Numbers 
and Sequences") the authors give the same equations, without including the 
std, but with the cos and sin terms outside the radical. They call this the 
Box-Muller (umlaut over the u) method, by the way. They also give another 
way of generating a zero-mean, unit-variance Gaussian random variable: 


Y = (sum from k=1 to 12) (U(k) - 6.0) 
where U(k) is a uniformly distributed random number in the interval [0,1]. 


-- Jon, KE3Z 

From FORRERJ@frl.orst.edu Wed Nov 09 10:31:22 1994 

Return-Path: <FORRERJ@frl.orst.edu> 
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Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 9 Nov 94 8:30:49 PST8PDT 

From: "Johan Forrer 

FL" <FORRERJ@£rl.orst.edu> 

Organization: Forest Research Lab. Oregon State 

To: hfsig@tapr.org 


Date: Wed, 9 Nov 1994 08:30:39 PST8PDT 


Subject: Re: [HFSIG:86] Re: HF Modulation 
Priority: normal 
X-mailer: PMail v3.0 (Ria) 


Message-ID: <7784F8A797F@frl.orst.edu> 
Hi folks, 


Great contributions! Thanks. 


>> WGN_real = std * sqrt (-2*«ln(ran1)*cos(2*pixran2) ) 


>> WGN. TMag = ose acess eee ieee ee SLM at pater ce 

>> 

>> where: std is the std. dev. of GN, 

>> rani, ran2 is uniformly distributed between 0,1 


>Should the trig functions be inside the square root as shown? In the book 
>referenced above, (in section 3.11, "Computer Generation of Random Numbers 
>and Sequences") the authors give the same equations, without including the 
>std, but with the cos and sin terms outside the radical. They call this the 
>Box-Muller (umlaut over the u) method, by the way. They also give another 
>way of generating a zero-mean, unit-varliance Gaussian random variable: 

> 

>Y = (sum from k=1 to 12) (U(k) - 6.0) 

> 

>where U(k) is a uniformly distributed random number in the interval [0,1]. 
> 

> -- Jon, KE3Z 


Jon, you are right - the sqrt should only contain the "In(ran)" 
term, the sin/cos should be outside. 


Johan, KC7WW 


From gjones@tenet.edu Wed Nov 09 14:42:56 1994 

Return-Path: <gjones@tenet.edu> 

Received: from Kay-Abernathy.tenet.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxr5Jr2-00010PC; Wed, 9 Nov 94 14:42 CST 

Received: (from gjones@localhost) by Kay-Abernathy.tenet.edu (8.6.9/8.6.9) id 

0AA15915 for hfsig@tapr.org; Wed, 9 Nov 1994 14:42:49 -0600 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199411092042.0AA15915@Kay -Abernathy.tenet.edu> 

Subject: Asst HFSIG Chair/Scribe Needed 

To: hfsig@tapr.org (HF SIG mailing) 

Date: Wed, 9 Nov 1994 14:42:48 -0600 (CST) 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 839 


Hi Folks. 
Have really enjoyed reading the threads so far. 


I have been speaking to Johan and we both feel that the HFSIG needs an asst 
chair/scribe. This position would handle writing up the quarterly report on 
the HF SIG for the TAPR PSR. 


While all the threads are kept on file, having the overview report each 
quarter in the PSR makes what the HF SIG does a part of the running history 
of TAPR and digital communications. 


Also, the part of the Asst Chair is to help Johan organize things as they 
need to be done regarding the SIG from time to time when he does not have 
time. As well, the ast chair would be responsible if anything happens to the 
chair in the future. Keeping continuity is very important and the asst 

chair position will help with that. 


If you think you are interested, contact Johan or me. 


Cheers - Greg 


From mcdermot@eagle.aud.alcatel.com Wed Nov 09 16:20:51 1994 

Return-Path: <mcdermot@eagle.aud.alcatel.com> 

Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOx5LN1-0001GzC; Wed, 9 Nov 94 16:20 CST 

Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
id AAQ9725; Wed, 9 Nov 94 16:20:23 CST 

Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ7033; Wed, 9 Nov 94 16:20:21 CST 

Date: Wed, 9 Nov 94 16:20:21 CST 

From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 

Message-Id: <9411092220.AA07033@eagle.aud.alcatel.com> 

To: hfsig@tapr.org 

Subject: CCIR via GOPHER 


For those who may be interested, you can get the complete 
listing of CCIR recommendations, and the text (with figures) of some of 
them electronically. The following gopher is available. I accessed it 
recently, and there's a wealth of information on line. This are the 
instructions I downloaded from the README file.... 


You can access the ITU/TIES information via gopher: 
- use your own gopher client and access to info.itu.ch on port 70 


or 
- telnet to gopher.itu.ch on port 2000 


VV VV VV 


Please send any message to helpdesk@itu.ch 


The TIES group 


VV VV WV 


A search indicates that the most current version of CCIR 549 is -1, and it is 
about sidetone on handset for Shipboard radiotelehpone (there was a 

reference to this by one post recently). Not sure if I copied the number 
correctly or not! The other one, was 520-2, and -2 is the current version. 
It is on HF channel simulation. Unfortunately it is not available 
electronically. 


- Tom, N5EG 


From FORRERJ@frl.orst.edu Wed Nov 09 18:05:00 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxr5NOZ-O001FVC; Wed, 9 Nov 94 18:04 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id IAA19121 for <hfsig@tapr.org>; Wed, 9 Nov 1994 08:43:46 
-0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Wed, 9 Nov 94 16:04:33 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 9 Nov 94 16:04:15 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Wed, 9 Nov 1994 16:04:07 PST8PDT 
Subject: Re: [HFSIG:89] CCIR via GOPHER 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <77FDE6DOQEF@frl.orst.edu> 


> For those who may be interested, you can get the complete 

>listing of CCIR recommendations, and the text (with figures) of some of 
>them electronically. The following gopher is available. I accessed it 
>recently, and there's a wealth of information on line. This are the 
>instructions I downloaded from the README file.... 


> 

>> 

>> You can access the ITU/TIES information via gopher: 

>> 

>> - use your own gopher client and access to info.itu.ch on port 70 
>> or 

>> - telnet to gopher.itu.ch on port 2000 

>> 


>> Please send any message to helpdesk@itu.ch 
>> 


>> The TIES group 


> 

> 

>A search indicates that the most current version of CCIR 549 is -1, and it 
>is about sidetone on handset for Shipboard radiotelehpone (there was a 
>reference to this by one post recently). Not sure if I copied the number 
>correctly or not! The other one, was 520-2, and -2 is the current version. 
>It is on HF channel simulation. Unfortunately it is not available 
>electronically. 

> 

> 

> - Tom, N5EG 


Hi Tom, 


It would be helpful to access the ITU/CCIR sources electronically. I thought 
that it was only available to certain member organizations - but maybe not. 

I'm not sure about the nomenclature - the documents that I have in front of 

me are titled: 


"Report 549-2, HF Ionospheric channel simulators", and 
" Recommendation 520-1, Use of high frequency ionospheric simulators". 


Is it possible that the recommendations and reports are different 
documents? Can anyone help clarify this? 


I read the Ehrman paper - quite interesting and takes you a step closer to 
doing it: there they sampled the input signal at 51.6ksps, filtered it, 
decimated 6:1 before Hilbert-transforming it to produce real and imag. 
components for the tapped delay lines. A fairly understandable description 
follows on how each of the delayed paths are processed to introduce Raleigh 
fading and doppler. Also given are how broad-band and impulse noise are 
treated. On the practical side, seems like they had the randomized Gaussian 
number generator and complex exponential generator as table lookups. The 
question remains whether this could all be done using fixed point or whether 
it needs floating point. It would be real nice if it could all be done on 
the DSP hardware without too much involvement from the host (except for 
configuration and downloading). Would someone like to comment on that? 


Johan, KC7WW 

From mcdermot@eagle.aud.alcatel.com Thu Nov 10 10:45:15 1994 

Return-Path: <mcdermot@eagle.aud.alcatel.com> 

Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOr5ccX-0001zWC; Thu, 10 Nov 94 10:45 CST 

Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
id AAQQ655; Thu, 10 Nov 94 10:44:46 CST 

Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ7689; Thu, 10 Nov 94 10:44:45 CST 

Date: Thu, 10 Nov 94 10:44:45 CST 

From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 


Message-Id: <9411101644.AA07689@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Ehrman paper 


I got a copy of the Ehrman paper (IEEE ComTech Vol. 30, No. 8, August 
1982), "Real-Time Software Simulation of the HF Radio Channel". This is a 
really good how-to paper. It clarifies many of the thoughts that were left 
somewhat vague by the Watterson paper. Highly recommended reading. 


- Tom, N5EG 
From mcdermot@eagle.aud.alcatel.com Fri Nov 11 09:43:07 1994 
Return-Path: <mcdermot@eagle.aud.alcatel.com> 
Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOr5y7z-Q0O00yUC; Fri, 11 Nov 94 09:43 CST 
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
id AAQ1226; Fri, 11 Nov 94 09:42:31 CST 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ8376; Fri, 11 Nov 94 09:42:29 CST 
Date: Fri, 11 Nov 94 09:42:29 CST 
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9411111542 .AA08376@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:86] Re: HF Modulation 


Should the trig functions be inside the square root as shown? In the book 
referenced above, (in section 3.11, "Computer Generation of Random Numbers 
and Sequences") the authors give the same equations, without including the 
std, but with the cos and sin terms outside the radical. They call this the 
Box-Muller (umlaut over the u) method, by the way. They also give another 
way of generating a zero-mean, unit-variance Gaussian random variable: 


Y = (sum from k=1 to 12) (U(k) - 6.0) 
where U(k) is a uniformly distributed random number in the interval [0,1]. 


-- Jon, KE3Z 


VVVV VV VV VV VV NV 


I used EXCEL to generate 500 random numbers using Jon's formula, and 
plotted the histogram, both pdf (probability density) and cdf (cummulative 
density). Both the pdf and the cdf look very much like those for gaussian 
functions. The mean is zero (obvious by inspection) and the standard 
deviation is 1.0 (not so obvious by inspection?). Given the lack of needing 
a log() or 1In() function, this formula may be easier to generate ona 
fixed-point DSP engine. Ehrman gives a simple formula for a random number 
generator if a 32-bit accumulator is available. Thanks for the info, Jon. 


- Tom, N5EG 
From chbrain@dircon.co.uk Sat Nov 12 05:10:10 1994 
Return-Path: <chbrain@dircon.co.uk> 
Received: from felix.dircon.co.uk by dptspd.sat.datapoint.com with smtp 


(Smail3.1.28.1 #3) id mOr6GLO-0000xZC; Sat, 12 Nov 94 05:10 CST 
Received: from aaQQ2.pool.dircon.co.uk by felix.dircon.co.uk with SMTP id AAQ4501 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 12 Nov 1994 11:08:03 GMT 
Date: Sat, 12 Nov 1994 11:08:03 GMT 
Message-Id: <199411121108.AA04501@felix.dircon.co.uk> 
X-Sender: chbrain@dircon.co.uk 
X-Mailer: Windows Eudora Version 1.4.3b4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
To: hfsig@tapr.org 
From: chbrain@dircon.co.uk (Charles Brain) 
Subject: Bandwidth 


I just thought you might like to know what the U.K licence says about bandwidth. 


" The bandwidths of emmissions should be such as to ensure the most 
efficient utilisation of the spectrum; in general this requires that 
bandwidths be kept at the lowest values which technology and the nature of 
the service permit. Where bandwidth-expansion techniques are used, the 
minimum spectral power density consistent with efficient spectrum 
utilisation should be employed." 


This I take to mean, is that there is nothing precluding the use of voice 
bandwidth data modems on H.F. 


Just got my QEX interesting article Johan. 


Regards Charles 
| Charles Brain (G4GUO) | 
| Chelmsford, Essex. 
| E-mail chbrain@dircon.co.uk | 
| POTS +44 (0)1245 353221 | 
| FAX +44 (0)1245 275448 | 


From mcdermot@eagle.aud.alcatel.com Mon Nov 14 08:10:52 1994 

Return-Path: <mcdermot@eagle.aud.alcatel.com> 

Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id m0xr727M-OQOOOQWIC; Mon, 14 Nov 94 08:10 CST 

Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
id AA16058; Mon, 14 Nov 94 08:09:34 CST 

Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AA12712; Mon, 14 Nov 94 08:10:28 CST 

Date: Mon, 14 Nov 94 08:10:28 CST 

From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 

Message-Id: <9411141410.AA12712@eagle.aud.alcatel.com> 

To: hfsig@tapr.org 

Subject: Channel simulator math 


Johan: 


I spent some time reviewing the Ehrman article, and this is my 
understanding of the math involved: 


The input is real-valued, but a pseudo-imaginary stream is generated 
via a hilbert transform (wideband 90-degree phase shift). I found a suitable 
program for generating coefficients in Burrus & Parks, "Digital Filter Design" 
but do not have access to the reference [7, Rabiner] where the efficiency can 
be doubled by using an odd number of taps. Interestingly, an even number of 
taps generates a high-pass transform, an odd number of taps must generate a 
band-pass transform [B&P]. 


Two independent gaussian-distributed random variables modulate the 
I,Q components of the vector modulator for each tap. The random numbers are 
filtered by a low pass filter with appropriate time constant. I am guessing 
that a random number that is low pass filtered still has the same random 
distribution statistics as before filtering (except for frequency of course), 
this appears to be Ehrman's assumption. 


The Doppler shift is done by a vector modulator with the variable 
being a constant-rotating phase shift, but with no random component. The 
rotating phase generates the + or - doppler freqency offset. The gaussian 
frequency doppler spread is caused by the first modulator (in the previous 
paragraph) since it had to contribute random phase changes. 


Does this agree with your interpretation? 


Johan, I very much appreciate the references to the various articles, 
as they speed up considerably finding and understanding the material! Trying 
to find all the relevant articles is slow and laborious, and that's one of 
the good things about the newsgroup - getting those important references 
found. I did acquire a copy of both CCIR reports/recommendations you 
suggested, but have not read them yet. 


- Tom, N5EG 
From FORRERIJ@frl.orst.edu Mon Nov 14 10:34:05 1994 
Return-Path: <FORRERIJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxr74LE-O001KYC; Mon, 14 Nov 94 10:33 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAAO7160 for <hfsig@tapr.org>; Mon, 14 Nov 1994 
01:11:22 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Mon, 14 Nov 94 8:32:20 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 14 Nov 94 8:32:18 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Mon, 14 Nov 1994 08:32:14 PST8PDT 
Subject: Re: [HFSIG:94] Channel simulator math 
Priority: normal 
X-mailer: PMail v3.0 (Ria) 


Message-ID: <7FQ595A4D2D@frl1.orst.edu> 


>Johan: 

> 

> I spent some time reviewing the Ehrman article, and this is my 
>understanding of the math involved: 

> 

> The input is real-valued, but a pseudo-imaginary stream is generated 


>via a hilbert transform (wideband 90-degree phase shift). I found a 
>suitable program for generating coefficients in Burrus & Parks, "Digital 
>Filter Design" but do not have access to the reference [7, Rabiner] where 
>the efficiency can be doubled by using an odd number of taps. 
>Interestingly, an even number of taps generates a high-pass transform, an 
>odd number of taps must generate a band-pass transform [B&P]. 


Yes, an analytical signal is formed, though of course you may also achieve 
Similar results by down-converting in frequency domain at the input, anda 
Similar up-conversion at the output, however, using the Hilbert pair saves a 
few computations. One thing that are implied in most of the papers so far, 
is that, if you do use the Hilbert transformer, its delay must be 
compensated by a similar delay in the "I" branch. A neat description of 
this is given in: "Theory and Implementation of a Slitband Modem Using the 
TMS32010" by George Troullinos et al. SPRAO13. If you ask nicely, the folks 
at TI's Literature Distribution will give it away for free. I actually have 
based my simulator on the filters that are given in this booklet. If you 
look at the coefficients that they provide in the above article, you will 
see the effect of the odd number of taps, i.e. half the coeffients are 
zero. There is, however, some concern of spurious harmonics due to 
imperfections in the transform that should ideally be removed by LPF. I'm 
not too sure how important all this would be in real applications. 


> Two independent gaussian-distributed random variables modulate the 
>I,Q components of the vector modulator for each tap. The random numbers 
>are filtered by a low pass filter with appropriate time constant. I am 
>guessing that a random number that is low pass filtered still has the same 
>random distribution statistics as before filtering (except for frequency 
>of course), this appears to be Ehrman's assumption. 

> 

> The Doppler shift is done by a vector modulator with the variable 
>being a constant-rotating phase shift, but with no random component. The 
>rotating phase generates the + or - doppler freqency offset. The gaussian 
>frequency doppler spread is caused by the first modulator (in the previous 
>paragraph) since it had to contribute random phase changes. 

> 

> Does this agree with your interpretation? 


Yes, basically this is how I understand it too, and also from the plots that 
I have generated, looks feasible. Multiplication is distributive of course 
and you may perform the multiplications in any order. What I do is 

to first generate the complex Gaussian signal, LPF, then mix the doppler 
signal and last, mix the complex signal from the input delay line. You may 
find however, that the sample rate at the Gaussian/doppler pair are at 

much lower rate than the input sampling, i.e. around the hundred SPS 

range (due to the very low frequencies generated at that point) vs. the 
input signal needs to be sampled at least twice 3 KSPS (which incidentally, 
I choose 9600 SPS). This means that you will need an interpolating filter at 
the gain tap functions else the signals there will be very ragged steps. 


This brings me to another issue that the Ehrman paper is very loose on. If 
you are creating three signals that need to be combined, you need to ensure 
that they have equal power - how do you go about that? Also if the Gaussian 
generator has to be LPF'd, it will change its power, so you need to 
compensate for that when you choose your variance when generating the 
Gaussian signal. 


> Johan, I very much appreciate the references to the various articles, 
>as they speed up considerably finding and understanding the material! 
>Trying to find all the relevant articles is slow and laborious, and that's 
>one of the good things about the newsgroup - getting those important 
>references found. I did acquire a copy of both CCIR 
>reports/recommendations you suggested, but have not read them yet. 

> 

> - Tom, N5EG 


Ditto - goes without saying that I am grateful for all the participation. I 
do hope that you will consider writing all of this up some time ina 
article? 


73's 


Johan, KC7WW 
From FORRERJ@frl.orst.edu Mon Nov 14 10:55:53 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxr74h4-O00021RUC; Mon, 14 Nov 94 10:55 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAAOQ7207 for <hfsig@tapr.org>; Mon, 14 Nov 1994 
01:18:17 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Mon, 14 Nov 94 8:39:16 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 14 Nov 94 8:39:04 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 


Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 14 Nov 1994 08:38:55 PST8PDT 
Subject: Re: [HFSIG:93] Bandwidth 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <7F0763671E2@frl.orst.edu> 


Charles, 


>I just thought you might like to know what the U.K licence says about 
>bandwidth. 


>" The bandwidths of emmissions should be such as to ensure the most 
>efficient utilisation of the spectrum; in general this requires that 
>bandwidths be kept at the lowest values which technology and the nature of 
>the service permit. Where bandwidth-expansion techniques are used, the 
>minimum spectral power density consistent with efficient spectrum 
>utilisation should be employed." 

> 

>This I take to mean, is that there is nothing precluding the use of voice 
>bandwidth data modems on H.F. 


Makes sense - does'nt it. 


>Just got my QEX interesting article Johan. 


Hope you enjoy the article. BTW, I have been meaning to talk to you about 
your table-lookup approach of doing Golay encoding/decoding. Will leave it 
for another opportunity. 


> Regards Charles 


> a at nis as = ln ge cg waa: ae 2h ot tag Seats 6 la? at gee Sets 
> | Charles Brain (G4GUO) | 
> | Chelmsford, Essex. | 
> | E-mail chbrain@dircon.co.uk | 
> | POTS +44 (0)1245 353221 | 
> | FAX +44 (0)1245 275448 | 
> oon ih sm a) Tl a, ey as “Sem ee, «i, fe ,  ga 
73's 


Johan, KC7WW 

From Rick_Whiting@ATK.COM Mon Nov 14 16:09:32 1994 
Return-Path: <Rick_Whiting@ATK.COM> 

Received: from ATK.COM by dptspd.sat.datapoint.com with smtp 


(Smail3.1.28.1 #3) id mOxr79a0-0001dwC; Mon, 14 Nov 94 16:09 CST 
Received: from gateway1 by ATK.COM (8.6.9/8.6.9) 
id QAA13965; Mon, 14 Nov 1994 16:09:06 -0600 
Message-Id: <199411142209.QAA13965@ATK.COM> 
Date: 14 Nov 1994 16:09:14 -0600 
From: "Rick Whiting" <Rick_Whiting@ATK.COM> 
Subject: Channelization 
To: "Post hfsig TAPR" <hfsig@tapr.org> 


Subject: Time:4:04 PM 
OFFICE MEMO Channelization Date:11/14/94 


I recall it has been suggested that the 500 Hz bandwidth proposed 

for semiautomatic unattended operation on HF (in the U.S.) originated from an 
idea for "channelizing" digital operations to reduce interference. 

Regardless of the merits (or lack thereof) of establishing a limit on 
bandwidth, I wonder if channelization really would increase 

throughput on HF under the scenario described below. 


Intuitively, channelization would benefit CSMA modes, e.g., AX.25. 

But it is not clear (at least to me) that channelization will necessarily 
provide the greatest throughput for the most users of a given HF 
sub-band for non-CSMA modes, particularly those employing FEC. It 
strikes me that for protocols such as PACTOR and G-TOR it might be 
possible that more stations would pass more total data by the 

somewhat unstructured process currently employed, i.e., find the 

least noisy channel and "jump in." It would be interesting to see the 
results of a simulation of both channelized and non-channelized 
operation given realistic band conditions and station geographic 
distribution. 


Of course, if the idea is to provide the best possible throughput to a 
limited number of stations at any time, then "rationing" operation to 
(clear) channels will provide maximum available throughput for the 
lucky few. But, laying aside the philosophical question of quality vs. 
quantity, is there any answer to the original hypothesis that non- 
channelization will maximize total throughput on HF in a real world 
scenario of "many" pairs of stations attempting to communicate? 


From Rick_Whiting@ATK.COM Mon Nov 14 16:28:35 1994 
Return-Path: <Rick_Whiting@ATK. COM> 
Received: from ATK.COM by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOr79t2-0001UpC; Mon, 14 Nov 94 16:28 CST 
Received: from gateway1 by ATK.COM (8.6.9/8.6.9) 
id QAA14231; Mon, 14 Nov 1994 16:28:28 -0600 
Message-Id: <199411142228 .QAA14231@ATK.COM> 
Date: 14 Nov 1994 16:29:34 -0600 
From: "Rick Whiting" <Rick_Whiting@ATK.COM> 
Subject: Channelization 
To: "Post hfsig TAPR" <hfsig@tapr.org> 


Subject: Time:4:25 PM 
OFFICE MEMO Channelization Date:11/14/94 
Sorry, I forgot my mailings to hfsig don't append a signature. So I hereby 
confess to posting the earlier message re channelization. 


73/Rick WOTN 


From esilbaug@afit.af.mil Mon Nov 14 19:23:05 1994 

Return-Path: <esilbaug@afit.af.mil> 

Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp 

(Smail3.1.28.1 #3) id mOr7Cbt-0001gqC; Mon, 14 Nov 94 19:23 CST 

Received: from grouse.afit.af.mil by stealth.afit.af.mil with SMTP id AAQ2585 
(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Mon, 14 Nov 1994 20:22:57 -0500 

Date: Mon, 14 Nov 1994 20:22:57 -0500 
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Subject: Re: Channel simulator math 

Cc: esilbaug@afit.af.mil 


Tom, 


If you want more info on Hilbert transforms you might try looking 
for "Discrete-time Signal Processing" by Oppenheim and Schafer. 

It's one of the 'classic' DSP texts and should be in most university 
libraries. Chapter 10 is devoted entirely to Hilbert transforms. 


Johan's comments on delay and coefficients are exactly correct. 

Now for more gory details. You probably also noticed that the 
coeficients of the Hilbert transform have odd symetry. In other 
words, X[n] = -X[-n]. These coeficients have the same magnitude but 
opposite sign. Now, combine this with the fact that half the 
coeficients are identically zero for Hilbert transforms with an odd 
number of taps. (Note that Hilbert transforms with an even number of 
taps have non-zero coefficients for all taps) 


Because of these nice properties we don't have to compute the response 
for half the taps. We can also take the difference of the input data 
corresponding to taps with equal magnitudes and multiply this 
difference once by the coeficient. These properties reduce the number 
of multiplications by a factor of 4 and halve the number of additions. 
Pretty good, and we haven't even broken a sweat! 


Another nice property is that these Hilbert transforms have linear 
phase because of the symetric coeficients. You get an xexactx 90 
degree phase shift, plus a constant delay. The problem is that the 
magnitude response has ripples (Yes, like the potato(e) chip). 


The Ehrman paper mentions having an error of less than -50 dB (I 
presume they mean ripple error) in their Hilbert transform. In my 


experience this would mean a filter with ~40-60 taps, depending on the 
required bandwidth. The number of taps required increases quickly if 
you need accurate response near the band edges (0 Hz and Nyquist 
frequency). 


Well, now that I've completely bored you...later. 
Eric 


Z Pe “ Eric E. Silbaugh 
Ba 338 esilbaug@afit.af.mil 
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This is a bit off the technical track, but I am looking for a clear, 
concise publication that explains hf communications to the lay person. 
CODAN, the Australian manufacturer, used toput out such a book, but alas, 
I need something more vendor generic. 


At VITA, we field HF packet radio systems in developing countries, and 
explaining why things do or don't work in their language is the toughest 
job of all! 


Thanks -- 
Eric 


Eric Rosenberg 

Volunteers In Technical Assistance voice: +703-276-1800 

1600 Wilson Blvd., Suite 500 fax: +703-243-1865 

Arlington, VA 22209 USA ericr@vita.org 
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To: hfsig@tapr.org 
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Subject: Ideas for HF modulation and coding 


After the last Dayton Hamvention, W3IWI and I drove to Baltimore and 
we discussed at length some ideas I had for a "moonbounce modem". We 
eventually came to the conclusion that if my scheme worked via the 
moon, it should work even better over HF. 


First, some background. 


The basic problem is that you're operating over a dispersive, fading 
channel. Received phase is essentially random, so coherence is hard to 
achieve. But it turns out that you can buy back much of the loss of 
noncoherent demodulation -- at the cost of increased bandwidth -- with 
m-ary orthogonal signalling. 


"Orthogonal" simply means that the signal states are independent of 
each other. You can build a detector that responds to one signal 
state while remaining completely unaffected (in theory) by the other 
states. Plain mark/space FSK is 2-ary orthogonal signalling, assuming 
the shift is large enough for the signalling rate. You can detect FSK 
with two properly tuned filters, and (again in theory) the mark filter 
does not respond at all to a space signal, and vice versa. 


Ordinary BPSK is not orthogonal, it's antipodal. One state is the 
exact opposite of the other, so instead of being independent, they 
"fight" each other much like a tug-of-war contest. You use a single 
detector and compare the result to a threshold. Antipodal modulation 
is 3dB better than orthogonal modulation but it requires phase 


coherence, which we don't have on HF. 


So we're stuck with orthgonal signalling. But instead of being limited 
to only two antipodal signal points, you can have as many orthogonal 
signal points as you like. In m-ary orthogonal signalling, you have m 
possible channel states, where m is usually a power of 2. E.g., 
4-tone FSK is a 4-ary orthogonal modulation scheme. Each channel 
symbol carries 2 bits of information in the 242 = 4 possible states, 
assuming only one of the four tones is on at any time (otherwise you'd 
just have several 2-ary systems in parallel.) 


It turns out that as m approaches infinity, overall performance 
asymptotically reaches the theoretical Shannon limit of -1.6dB Eb/NO, 
even with noncoherent demodulation! This has been known for a long 
time, but unfortunately the improvement with m is too slow to be 
impractical. 


Given that, here's my idea. Take a reasonable channel bandwidth, say 2 


Khz since that will fit through most SSB filters. Divide this 2 Khz 
into 256 frequency bins, each 7.8125 Hz wide. In order to keep the 
bins independent and orthogonal, our signalling rate will be limited 
to no more than 7.8125 symbols per second. But we want a slow symbol 
rate anyway to minimize intersymbol interference caused by ionospheric 
multipath. Also, synchronization is easier at a low symbol rate; it 
may even be possible to use GPS with approximate propagation delay 
figures to synchronize "open loop". Anyway, with that many bins we 
could send log2(256) = 8 bits per symbol, or 62.5 bits/sec. 


Although this scheme by itself is orthogonal, it isn't particularly 
resistant to selective fading or narrowband interference. To improve 
this I propose another layer of orthogonal coding using Walsh 
functions (rows of a Hadamard matrix). 


A Hadamard matrix is easily built up recursively. You start with a 1x1 
matrix containing the single entry "1". Then you double each dimension 
of the matrix by copying it to the right and below unchanged, and 
diagonally to the lower right by inverting each bit. Here's the 
recurrence relation defined using the limited graphics of ASCII: 


M(it+1) = M(i) M(i) 
M(i) ~M(i) 


You can keep repeating this process until you have a matrix of the 
desired size. Here are the first few Hadamard matrices: 


1 


11 
10 


1111 
1010 
1100 
1001 


11111111 
10101010 
11001100 
10011001 
11110000 
10100101 
11000011 
10010110 


and so forth. 


Now notice that if you take any two rows at random from a Hadamard 
matrix and XOR them bitwise, you'll always get an equal number of 1's 
and O's. It's easy to see how this follows from the recursive 
definition given above. 


This property means that the rows (and the columns, for that matter) 
of a Hademard matrix form a set of mutually orthogonal 

functions. These are called Walsh functions, and have been around for 
a long time. (As an aside, one clever use in the early days of 
telephony was to set up wire-crossing patterns for parallel open-wire 
transmission lines in order to minimize inductive crosstalk.) 


Now let's say that instead of just turning on one tone (out of 256) at 
a time for each transmitted symbol, we take the 8-bit symbol and index 
the corresponding row from a 256x256 Hadamard matrix. The 256 bits in 
that row then control whether or not the tone is turned in each of 256 
frequency bins. (The amplitude of each tone is reduced to keep the 
transmitter power the same.) 


Each symbol still carries only 8 bits, so the energy per bit is the 
same in this scheme as with the simple 1-tone-out-of-256 

scheme. Moreover, for every Walsh codeword except the all-1s case, 
exactly 50% of the bins are on and 50% are off, so the transmitter 
power is constant. (The all 1's case could be avoided with some work 
if necessary.) 


So performance with and without Walsh coding should be exactly the 
same over a nonfading gaussian noise channel. But HF has both 
non-gaussian (e.g., narrowband) interference and fading, often of the 
frequency-selective kind. Walsh encoding should help by spreading each 
symbol's energy out more evenly over the frequency channel. 


You could demodulate this signal by first taking a FFT of the raw 
input samples to determine the total received energy in each frequency 
bin. Then you take the FHT (Fast Hademard Transform, analogous to the 
FFT) to determine which of the 256 Walsh functions was mostly likely 
to have been the one that was sent. 


Note that the first column in each of the Hademard matrices is a 1, 
which is rather redundant. You could omit it and save a frequency bin 
(which is pretty minor). This is called a "simplex" code, as opposed 
to a straight orthogonal code. But you could do much better by 
augmenting the matrix with each bit inverted, doubling the number of 
code words and adding a bit to each symbol. For example, if we take 
the 4x4 Hademard matrix 


1111 
1010 
1100 
1001 


and append to it its bit-inverse, we get 


1111 
1010 
1100 
1001 


0000 
0101 
0011 
0110 


The 8 rows are now either mutually orthogonal (equal number of bit 
agreements and disagreements) or antipodal (all bits disagree). 


This is called a "biorthogonal" code, and in fact it's one of the 
earliest error correcting codes used in spacecraft. Mariner 9 used one 
(64x32, I think) at Mars in the late 1960s, before the big switch to 
convolutional coding. 


The only reason to prefer a simplex or orthogonal code set over a 
biorthogonal code is when your channel has a polarity ambiguity (e.g., 
BPSK). You could easily determine polarity with an orthogonal or 

simplex code, but not with a biorthogonal code. But we don't have that 
problem here, since each "bin" is basically an on-off keyed channel without 
any polarity ambiguity. 


If we built a 128x128 Hademard matrix and turned it into a 
biorthogonal code we could send 8-bit symbols with only 128 frequency 
bins. This would let us double our symbol rate to 15.625/sec, or our 
raw bit rate to 125 bits/sec. Or we could halve the transmitted 
bandwidth and keep the earlier data rate (more on bandwidth issues 
later). 


Although this scheme should be very robust, there will be bursts of 
QRM and deep flat fades too great for it to handle. We could deal with 
this by adding another layer of FEC. A natural choice would be a 
Reed-Solomon block code over GF(2%8). This code operates on 8-bit 
symbols that matche the basic channel symbol. Paul, N9FZX has already 
implemented a Reed-Solomon decoder for 8-bit symbols and has made it 
freely available over the net. Although the natural block size for a 
RS coder over GF(256) is a 255-byte block, you can use a smaller 
blocksize if you like by just agreeing between sender and receiver 
that the unused symbols are Os and not sending them. On the other 
hand, larger blocksizes are more robust for the same amount of 
redundancy. 


A more complicated scheme that might work better is convolutional 
encoding with soft decision decoding, either Fano or Viterbi. The 
convolutional decoding itself is not a big problem (I've already 
implemented and tested both decoders) but what makes it complicated is 
the need to modify the Walsh function demodulator to provide soft 
samples (instead of "hard" 1s and Os) for each bit of each demodulated 
symbol. There are ways to do this, but they involve a fair amount of 
effort. I need to look into this. 


I also need to look into the optimality of the biorthogonal 

scheme. For maximum efficiency you like to have a channel code where 
every possible error event is of equal probability, but the 
biorthogonal code doesn't do this. (The probability of one codeword 


being turned into its antipodal complement is obviously much less than 
the probability of it being turned into another codeword that is 
merely orthogonal to it, since the hamming distance between antipodal 
codewords is twice that of the distance between two orthogonal 
codewords.) If you can't keep the codewords at equal distance, it 
might help to take them into account in your upper layer FEC design. 
Or it might not make a big difference, I don't know. 


I'm aware that mixing a large number of discrete tones would increase 
the variance of the instantaneous transmitter power. My intuition and 
the central limit theorem tells me that the instantaneous envelope 
power will end up looking very Gaussian. But Shannon says that 
efficient modulation schemes xhavex to look Gaussian, and it may turn 
out that the increased coding gain of this scheme more than makes up 
for any increased amplifier losses over a constant-envelope signal. 


So in summary, my scheme would take a block of 8-bit data bytes, add 
an appropriate number of Reed-Solomon FEC symbols, encode each symbol 
into a (128,8) biorthogonal channel code, and then use each of the 128 
channel bits to gate a set of 128 discrete channel tones. 


Some remarks on bandwidth. The bandwidth efficiency of this scheme may 
at first glance appear to be unacceptably low, especially for HF. 125 
bits/sec in 2 Khz is only 0.0625 bits/sec/Hz. But the more I learn 
about information theory both from the textbooks and from my work here 
at Qualcomm, the more I really understand that it's counterproductive 
to limit signal bandwidth. In the real world of a shared band, power 
efficiency and interference resistance are FAR more important, and 
these two properties are possible ONLY with extra bandwidth. 


This particular modulation scheme should be incredibly robust against 
both noise and QRM. It ought to be easily decodable well below the 
operator's ability to even hear it. Because of its spread 
spectrum-like properties, strong inband QRM can be notched out fairly 
easily. Since the energy distribution of the signal is fairly flat, 
after the FFT you just look for any frequency bins with energies way 
above average and suppress them before the FHT step. The only limit on 
the ability to suppress narrowband QRM (a CW carrier, say) then 
becomes the dynamic range of the receiver and A/D converter. 


So, what do people think? This stuff represents a radical departure 
from the usual approach of trying to minimize congestion by cramming 
as much as possible into a narrow HF channel. Because of its wide 
bandwidth, we'd need STAs to test my scheme on the HF bands, and a 
rule change for general use. But the FCC's bandwidth rules are based 
on intuition that happens to be completely wrong. John Costas said as 
much in his classic paper "Poisson, Shannon and the Radio Amateur", 
published 35 years ago, but now we actually have the technology to 
pursue his suggestions! 


Phil 
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In-reply-to: <199411160022 .QAA01412@servo.qualcomm.com> (karn) 

Subject: Re: Ideas for HF modulation and coding 


>time, but unfortunately the improvement with m is too slow to be 
>impractical. 


Uh, minor typo. That should be "too slow to be PRACTICAL by itself". 


Phil 
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In order to bring some levity to the heavy conversations on modulation 
schemes, I think it's time I add my two cents by way of introducing 
myself and expressing my interest in HF digital radio. 


My name is Eric Rosenberg, my callsign is WD3Q, and I live in 
Washington, DC. I've been licensed for 20+ years, and have lived and 
operated from NY, CA, SD, OH and PA before moving to DC in 1988. 


In addition, for the past three years my job has kept me overseas for 
long periods of time (too much, my wife says!), so I've managed to get 
licenses and operate from 9L, EI, F, G, J2, VK, YJ, and ZL (and listened 
from places where licenses were not available: YB and 9V). 


I work for a non-government development group called VITA: Volunteers in 
Technical Assistance. Many of you have heard of us through our 
satellite activities...we were the prime movers behind the Digital 
Communications Experiment on UO-11 and are the license holders and 


primary operators of the non-amateur activity on the U0O-14 satellite. In 
addition to the satellite work, we have also been involved in the design 
and implementation of terrestrial radio systems, mostly in Africa and 
Asia. 


To date we've installed systems in Chad, Sudan (2 systems), Philippines, 
Madagascar, and have assisted in the installation of systems in Lesotho, 
Sierra Leone, to name a few. The systems started out using AX.25, but 
have moved to 1200 bps PSK and more rrecently PacTOR. The distances 
between stations generally range from 200 - 1000km, with the average 
being 350 km. As the MUFs start moving down, we're now revisiting what 
we're putting out in the field. 


Our issues have rarely been technical...it is less important what 
modulation scheme is used than ability of that modem to be installed on 
a wide range of radios, from the Yaesu FT-747 (probably the single most 
common radio found in developing countries) to the more expensive 
commercial units made by Codan, Transworld, Harris, et al. It seems that 
each group we deal with has a smattering of radios, no two from the same 
manufacturer or age! 


The most important important issue is usability. Can the average, not 
terribly technically-minded person use this system effectively without 
having to become a trained radio operator. 


In the idealized world, we would like to see a system that incorporated 
some from of dynamic routing and ALE (Transworld's Transcall would 
suffice), user friendly software in the language of the user, and modems 
using modulation schemes that would interface to the wide range of 
radios we encounter. We've also done some work incorporating embedded 
controllers with the modems (this was done for a hands off, automated 
satellite network in Indonesia), and that looks like the real way to go. 


There's more, but these are the basics. 


To get to where we're going, VITA has just started to develop some 
unique applications, and hope to put up a multi-station experimental 
network to test it all out. We'll solicit you for help as it develops. 


One final note...the "Volunteers" in our name refers to you. We've had 
great participation from the amateur radio community in developing and 
fielding satellite and terrestrial systems. Rick Whiting, WOTN, did our 
first HF demo in Ethiopia in the mid 1980's, and we've had great help 
from KD6KQ, N3EOY, EL9GL, W2JUP, HB9AQZ, SMOTER, N6ARE and others. Norm 
Sternberg and now Rick Whiting and Dave Henderson (N3EOY) teach a class 
given yearly on low cost digital radio systems for the US 
Telecommunications Training Institute, a government-private partnership 
program that brings communications professionals from developing 
countries top the US for advanced training. 


I've been fascinated by the more esoteric discussions here. Just don't 
lose track of the users, please! 


Eric 


Eric Rosenberg WD3Q, J20BY, YJOAER, VK2GYA et al 
Volunteers In Technical Assistance voice: +703-276-1800 

1600 Wilson Blvd., Suite 500 fax: +703-243-1865 
Arlington, VA 22209 USA ericr@vita.org 
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Subject: Re: [HFSIG:95] Re: Channel simulator math 


Johan writes: 


Yes, basically this is how I understand it too, and also from the plots that 
I have generated, looks feasible. Multiplication is distributive of course 
and you may perform the multiplications in any order. What I do is 

to first generate the complex Gaussian signal, LPF, then mix the doppler 
Signal and last, mix the complex signal from the input delay line. You may 
find however, that the sample rate at the Gaussian/doppler pair are at 

much lower rate than the input sampling, i.e. around the hundred SPS 

range (due to the very low frequencies generated at that point) vs. the 
input signal needs to be sampled at least twice 3 KSPS (which incidentally, 
I choose 9600 SPS). This means that you will need an interpolating filter at 
the gain tap functions else the signals there will be very ragged steps. 


This brings me to another issue that the Ehrman paper is very loose on. If 
you are creating three signals that need to be combined, you need to ensure 
that they have equal power - how do you go about that? Also if the Gaussian 
generator has to be LPF'd, it will change its power, so you need to 
compensate for that when you choose your variance when generating the 
Gaussian signal. 


VV VV V VV VV VV VV VV VV VV WV 


It would seem that we could perform the interpolation after the 
multiplication and summation of all the components. As I recall, interpolation 
is really low-pass filtering, and as convolution (FIR filter) is 
associative (like multiplication), we should be able to just low-pass-filter 
the final output signal, assuming that no spurious mixing products are 
generated anywhere downstream of them complex Gaussian stream. Is this 
correct, and would it save a significant amount of processing? 


Also, it does not seem intuitive that we need to actually carefully 
match the received power in the three different components, since I 
see no reason why all three propagation components would actually have 
exactly the same efficiency in the real world. One of the CCIR documents 
recommends testing with the three compoenents set to different relative power 
and to the same relative power over about a 40 db range. 


Thanks for the informative comments from Johan and Eric. Hopefully 
this is all getting clear now. 


- Tom 
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Now let's say that instead of just turning on one tone (out of 256) at 
a time for each transmitted symbol, we take the 8-bit symbol and index 
the corresponding row from a 256x256 Hadamard matrix. The 256 bits in 
that row then control whether or not the tone is turned in each of 256 
frequency bins. (The amplitude of each tone is reduced to keep the 
transmitter power the same.) 


Each symbol still carries only 8 bits, so the energy per bit is the 
same in this scheme as with the simple 1-tone-out-of-256 

scheme. Moreover, for every Walsh codeword except the all-1s case, 
exactly 50% of the bins are on and 50% are off, so the transmitter 
power is constant. (The all 1's case could be avoided with some work 
if necessary.) 


VV VV VV VV VV VV OV 


> Phil 


Phil: a question: under this scheme, I agree that the power is 
constant, however it would seem that the peak amplitude could be very 
high. Would this require a great deal of linearity in the transmitter 
and receiver? 


- Tom, N5EG 
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> Phil: a question: under this scheme, I agree that the power is 
>constant, however it would seem that the peak amplitude could be very 
>high. Would this require a great deal of linearity in the transmitter 
>and receiver? 


Yes, it would. I address this particular point later on. I assert (without 
proof) that the coding gains would make up for any losses due to having 
to back off your amplifier to keep it linear. 


Phil 
From rs@ife.ee.ethz.ch Thu Nov 17 02:13:41 1994 
Return-Path: <rs@ife.ee.ethz.ch> 
Received: from bernina.ethz.ch by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOr81yM-00010VC; Thu, 17 Nov 94 02:13 CST 
Received: from ife (actually ife-gw.ethz.ch) by bernina.ethz.ch 
with SMTP inbound; Thu, 17 Nov 1994 09:13:23 +0100 
Received: from ife.ee.ethz.ch (chopin) by ife.ee.ethz.ch id AA24788; 
Thu, 17 Nov 1994 09:13:22 +0100 
Received: by ife.ee.ethz.ch id AAQQ226; Thu, 17 Nov 94 09:13:20 +0100 
Message-Id: <9411170813 .AAQ0226@ife.ee.ethz.ch> 
From: rs@ife.ee.ethz.ch (Rolf Sommerhalder) 
Subject: Re: [HFSIG:100] Documentation 
To: hfsig@tapr.org 
Date: Thu, 17 Nov 94 9:13:19 MET 
In-Reply-To: <Pine.3.89.9411151206.A16114-0100000@lan.vita.org>; from "Eric 
Rosenberg" at Nov 15, 94 11:29 am 
X-Mailer: ELM [version 2.3 PL11] 
content-length: 1074 


> At VITA, we field HF packet radio systems in developing countries, and 

> explaining why things do or don't work in their language is the toughest 
> job of all! 

Hi Eric 


Did you see the HF product catalog of SGC Corp. ? They have some 
general description of the art of HF radio comms in there which 


might be the level you are looking for. I can look up that 
companys address if you like to contact them. 


vy 73, 
Rolf 
(Swiss Disaster Relief, Telecom Group) 


P.S. 
We are enjoying VITA's WWW server to get the latest DHA reports... 
ee a a 


Rolf Sommerhalder 
Swiss Federal Institute of Technology (ETH) home address: 


Electronics Laboratory ETZ H60.1 c/o Rindlisbacher 
Gloriastrasse 35 Wermatswilerstrasse 96 
8092 Zurich / Switzerland 8610 Uster / Switzerland 
Voice +41 1 632 76 40 (or 632 51 53) Voice +41 1 941 59 28 
Fax +41 1 632 12 10 AX.25 HB9CWP @ HB90S 


E-Mail rolf.sommerhalder@ife.ee.ethz.ch 


From FORRERIJ@frl.orst.edu Fri Nov 18 11:12:08 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOr8Wqy-00015PC; Fri, 18 Nov 94 11:12 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAAO9766 for <HFSIG@tapr.org>; Fri, 18 Nov 1994 
01:50:58 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Fri, 18 Nov 94 9:11:04 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 18 Nov 94 9:10:51 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Fri, 18 Nov 1994 09:10:42 PST8PDT 
Subject: HF Simulator test results 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <851008E47FD@frl.orst.edu> 
Hi All, 


I have made a small test file containing test results from my efforts 
on the HF simultor. It is available for downloading via anonymous FTP from: 


ucs.orst.edu /tmp/HFSIM.ZIP 


This test was generated using a C program and simulating CCIR "GOOD", 
"MODERATE", "POOR" and "Flat fading" conditions. I still have to look more 


closely at intermediate results to check whether the magnitudes are OK, but 
results look like what is expected (I think?). 


I would appreciate your feedback on these results. 


The next step that I'm working on, is to implement the Hilbert transform, 
tapped delay lines, and complex mixers on the sound card. Since the 
Gaussian noise & doppler gain tap functions operates at a very low sample 
rate, I'm planning to let the PC generate these, and transfer the results 
over the ISA bus to the sound card for real time mixing. Perhaps I'll be 
able to listen to some real time simulations this weekend. 


73's 


Johan 

From mcdermot@eagle.aud.alcatel.com Fri Nov 18 11:39:30 1994 

Return-Path: <mcdermot@eagle.aud.alcatel.com> 

Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOx8XHR-QOOOkjC; Fri, 18 Nov 94 11:39 CST 

Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
id AA10591; Fri, 18 Nov 94 11:39:23 CST 

Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ3799; Fri, 18 Nov 94 11:39:21 CST 

Date: Fri, 18 Nov 94 11:39:21 CST 

From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 

Message-Id: <9411181739.AA03799@eagle.aud.alcatel.com> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:108] HF Simulator test results 


> Hi All, 

> 

> I have made a small test file containing test results from my efforts 

> on the HF simultor. It is available for downloading via anonymous FTP from: 
> 

> ucs.orst.edu /tmp/HFSIM.ZIP 

> 

> This test was generated using a C program and simulating CCIR "GOOD", 

> "MODERATE", "POOR" and "Flat fading" conditions. I still have to look more 

> closely at intermediate results to check whether the magnitudes are OK, but 
> results look like what is expected (I think?). 

> 

> I would appreciate your feedback on these results. 

> 73's 

> 

> Johan 

> 


Johan: congratulations on making so much progress on the simulator. 
You are way ahead of the rest of us. In looking through the data, I do not 
understand what the data represents. Is the numeric value a one-second 
average of the amplitude from summing all the components? 


- Tom, N5EG 
From shane@mdd.comm.mot.com Fri Nov 18 15:46:35 1994 
Return-Path: <shane@mdd.comm.mot.com> 
Received: from ftpbox.mot.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOr8b8Z-00019qC; Fri, 18 Nov 94 15:46 CST 
Received: from pobox.mot.com ([129.188.137.100]) by £tpbox.mot.com with SMTP 
(5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>) 
id AA24263; Fri, 18 Nov 1994 15:46:15 -0600 
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com) by pobox.mot.com with 
SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>) 
id AAQ8696; Fri, 18 Nov 1994 15:46:07 -0600 
Received: from daffyduck.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1) 
id AA24206; Fri, 18 Nov 94 13:45:55 PST 
Received: by daffyduck.mdd.comm.mot.com (4.1/SMI-4.1) 
id AA10734; Fri, 18 Nov 94 13:45:54 PST 
Date: Fri, 18 Nov 1994 13:45:54 -0800 (PST) 
From: Hugh Shane <shane@mdd.comm.mot.com> 
X-Sender: shane@daffyduck 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:101] Ideas for HF modulation and coding 
In-Reply-To: <199411160022 .QAA01412@servo.qualcomm. com> 
Message-Id: <Pine.SUN.3.90.941118132302 .1911W-100000@daffyduck> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Tue, 15 Nov 1994, Phil Karn wrote: 


Some remarks on bandwidth. The bandwidth efficiency of this scheme may 
at first glance appear to be unacceptably low, especially for HF. 125 
bits/sec in 2 Khz is only 0.0625 bits/sec/Hz. But the more I learn 
about information theory both from the textbooks and from my work here 
at Qualcomm, the more I really understand that it's counterproductive 
to limit signal bandwidth. In the real world of a shared band, power 
efficiency and interference resistance are FAR more important, and 
these two properties are possible ONLY with extra bandwidth. 


VV VV VV VV VV 


Hmmm... 


My point of reference is the work I've been doing here at Motorola. We 
build RF modems which operate at 19.2 kbps over 25 kHz channels for an 
efficiency of 0.768 bits/sec/Hz. The modulation scheme is 4-tone FSK with 
Trellis coding and forward error correction. Of course, the Trellis coding 
is overhead which reduces the effective bit rate. Does the larger 
bandwidth that we have available allow us greater efficiency than that of 
your proposed scheme? Do we approach some sort of limit (i.e. Shannon's) 
as the system becomes more spread-spectrum like? BTW, our products operate 
at VHF so we aren't too concerned about dispersion. However, we do have to 
deal with fading as they were originally designed for mobile applications, 
although they're finding their way into portable applications these days. 


So, what do people think? This stuff represents a radical departure 
from the usual approach of trying to minimize congestion by cramming 
as much as possible into a narrow HF channel. Because of its wide 
bandwidth, we'd need STAs to test my scheme on the HF bands, and a 
rule change for general use. But the FCC's bandwidth rules are based 
on intuition that happens to be completely wrong. John Costas said as 
much in his classic paper "Poisson, Shannon and the Radio Amateur", 
published 35 years ago, but now we actually have the technology to 
pursue his suggestions! 


VV VVVV VV VV MV 


I'm trying to hoist it all in! I'm somewhat of a newbie to HF data so I 
don't have too many preconceptions. If a wider channel allows greater 
efficiency and better immunity to QRM then it's hard to argue against 
this on strictly technical grounds. Of course there are politics &;) 


I haven't played with the sound card much yet. Is it fast enough to 
perform the transforms that you mention? Maybe benchmarking these 
algorithms would be a good place for me to get started? What do you say 
Johan? 


Hugh 
From Rick_Whiting@ATK.COM Fri Nov 18 17:42:55 1994 
Return-Path: <Rick_Whiting@ATK.COM> 
Received: from ATK.COM by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxr8cx4-000173C; Fri, 18 Nov 94 17:42 CST 
Received: from gateway1 by ATK.COM (8.6.9/8.6.9) 
id RAAQ2651; Fri, 18 Nov 1994 17:39:39 -0600 
Message-Id: <199411182339.RAAQ2651@ATK. COM> 
Date: 18 Nov 1994 17:40:02 -0600 
From: "Rick Whiting" <Rick_Whiting@ATK.COM> 
Subject: Bibliography 
To: "Post hfsig TAPR" <hfsig@tapr.org>, "Post Netsig TAPR" <netsig@tapr.org> 


Subject: Time:5:28 PM 
OFFICE MEMO Bibliography Date:11/18/94 
I recommend you add the following to your bibliography list if not your 
personal reference library: 


"Defining, Designing, and Evaluating Digital Communication Systems," by 
Bernard Sklar, IEEE Communications Magazine, Nov. 1993, pp. 92-101. 


The subtitle is "A tutorial that emphasizes the subtile but straightforward 
relationships we encounter when transforming from data-bits to channel-bits 
to symbols to chips." I'm not sure I agree with Dr. Sklar on the 
straightforwardness of it, but I do agree it's subtile. 


73 (and good reading!), 
Rick, WOTN 


From forrerj@ucs.orst.edu Mon Nov 21 10:52:26 1994 

Return-Path: <forrerj@ucs.orst.edu> 

Received: from ucs.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOr9byX-Q000QjC; Mon, 21 Nov 94 10:52 CST 

Received: by ucs.orst.edu; (5.65/1.1.8.2/24Sep94-1201PM) 
id AA28091; Mon, 21 Nov 1994 08:52:13 -0800 

Date: Mon, 21 Nov 1994 08:52:12 -0800 (PST) 

From: Johan Forrer <forrerj@ucs.orst.edu> 

Subject: HF Channel simultor 

To: HFSIG@tapr.org 

Message-Id: <Pine.3.89.9411210801 .A26685-0100000@ucs.orst.edu> 

Mime-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi All, 


For those interested in the HF channel simulator - I have available 

results of simulation runs that I did using a C program that I wrote for 

this purpose. These results shows the signal envelope of a 1200 Hz tone under 
CCIR: GOOD, MODERATE, POOR, and Flat fading conditions. Looks reasonable 

to me, but would like your input as well. 


The file is quite small, so I can mail it directly if you wish. 


73's 


Johan, KC7WW 
From FORRERJ@frl.orst.edu Tue Nov 22 12:45:20 1994 
Return-Path: <FORRERJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxrAODK-00016rC; Tue, 22 Nov 94 12:45 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id DAA28721 for <HFSIG@tapr.org>; Tue, 22 Nov 1994 
03:24:08 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 22 Nov 94 10:44:33 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 22 Nov 94 10:44:08 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERIJ@£rl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Tue, 22 Nov 1994 10:44:05 PST8PDT 
Subject: HF channel simulation 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <8B29162689D@frl.orst.edu> 
Greetings, 


My apologies for not responding - apparently I have a local e-mail problem 
and e-mail mail is "spotty" at best. I just retrieved the past week's 


discussion from the archive and saw Phil's interesting submission. 


The simulated data file is a one second snapshot, data points are taken 100 
ticks (at 9600 sps rate) apart, and represent the envelope of a 1200 Hz 
tone (no averaging - just the absolute value of the signal at that instant). 


Later experiments confirmed how critical the relative delay between 

the three taps are. I do not see any reference in the CCIR documents about 
this, basically it only specifies one value, i.e. 0.5ms, which I take 
refers to the overall delay between the first and last tap (which 
incedentally should be relatively prime). Now - where do one put the middle 
tap? Any suggestions? 


The interpolator filter is quite important. In my case I have to upsample 
at 1:100 rate which is not too good in one big step - I prefer to apply 

the usual multirate techniques here (these are complex-valued ofcourse). As 
far as I understand it, each tap requires it own separate multirate filter 
prior to mixing with the delay-line signals. That of course is separate 
from a LPF (a real-valued filter at this point) that is contained 

in the output, i.e. after all the real components have been added. Does it 
make sense? 


If you need my feedback - please e-mail me directly at the address below as 
receiving e-mail is unreliable at the moment. 


73's 
Johan, KC7WW 


forrerj@ucs.orst.edu 
(I also am on CI$ if you prefer that route). 


From FORRERJ@frl.orst.edu Tue Nov 22 13:14:52 1994 
Return-Path: <FORRERIJ@frl.orst.edu> 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxrAO£x-OO01F9C; Tue, 22 Nov 94 13:14 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id DAA29026 for <HFSIG@tapr.org>; Tue, 22 Nov 1994 
03:54:01 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 22 Nov 94 11:14:16 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 22 Nov 94 11:14:00 
PST8PDT 
From: "Johan Forrer 
FL" <FORRERJ@£rl.orst.edu> 


Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Tue, 22 Nov 1994 11:13:53 PST8PDT 
Subject: HF modulation 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <8B310D736EC@frl.orst.edu> 
Hi, 
After just briefly browsing through Phil's post - my $0.02. 


It is true that for practical reasons, non-coherent techniques makes a lot 
of sense. I just wonder though, whether we should totally disregard the 
possibility of extracting phase information with some reliability over HF 
links - this factor will play a key role of how we should trade off 
spectral efficiency and bandwidth efficiency. My question is: do we know 
enough to say yes or no at this point in time? I suspect we don't. 


If we judge from the experiences with of commercial MIL-STD-188 HF modems, 
we see that they do implement some of the things that Phil mentioned, i.e. 
orthogonal signalling in the form of 16 or 39 parallel carriers, however, 
each being phase modulated. I suspect that perhaps some tradeoff is 
possible and that is, IMHO, where we can made our contributions. 


Coding theory could do wonders when done right and perhaps should be part 
of the modulation as Phil suggest, however, I hope we do justice to 
modulation basics. I hope the simulator would help in providing some clues. 


If I had my druthers, I would have opted for SS, but that is perhaps 
looking too far into the future. Or is it? 


73's 


Johan, KC7WW 


P.S. pse e-mail me at: forrerj@ucs.orst.edu 


From BobH@eworld.com Sat Nov 26 06:07:02 1994 

Return-Path: <BobH@eworld.com> 

Received: from hpl.online.apple.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.28.1 #3) id mOxBLu6-QQQOQHBC; Sat, 26 Nov 94 06:06 CST 

Received: by hp1.online.apple.com 
(1.38.193.5/16.2) id AA12656; Sat, 26 Nov 1994 04:06:56 -0800 

From: BobH@eworld.com 

X-Mailer: AOS Mailer 

Sender: "BobH" <BobH@eworld.com> 

Message-Id: <9411260406.tn15861@eworld. com> 

To: hfsig@tapr.org 

Date: Sat, 26 Nov 94 04:06:48 PST 

Subject: [HFSIG] HF Channel Simulator 


H.F. Channel Simulator Validation 

Or 
Making Sure The Medium Is The Message 
And Not The Massage *( very droll, no? ) 


xWith apologies to Mr. McLuhan who I don't even pretend to understand. 


I'm new to the sig so I hope this topic hasn't been covered, or even 

worse, is obvious. 

In reading over the CCIR, it is clear that the statistics of the fading 
filter output are key to quality and appropriateness of the simulation. Other 
functions such as Doppler offset are more straight forward and easily 
measured (SNR calibration might also be a problem however). 

IMHO a couple of items must be verified to show compliance or surely 

any simulated performance of waveform, coding or protocol will quickly 
degenerated into a challenge to the simulator's channel transfer function. 

> From the CCIR "Two independent complex Gaussian ergodic random processes, 
each with zero mean values and independent real and imaginary components with 
equal r.m.s. values that produce Rayleigh fading..." must be generated. Any 
simulator validation must show the amplitude and phase of the complex fading 
envelope, for each path, to be Gaussian. This would include statistical tests 
for independence (to aid diversity schemes), mean, variance and a probability 
distribution histogram. Also, a simulator controller should provide the fade 
statistics to document any given test run. 

> Not independent but different, again from the CCIR "Each tap-gain function 
has a spectrum...that in general consists of the sum of two magnetonionic 
components, each of which is a Gaussian function of frequency" ( the 2 sigma 
points are given as a parameter ) and later "The importance of the shape of 
the tap-gain spectrum should be noted". This "double-sided smear bandwidth" 
should be measured in frequency and shown to have zero mean and unit standard 
deviation of accuracy over 2 or 3 sigma. 

Also, in my personal wish list for a channel simulator: the CCIR suggests a 
specular (non-fading) component for a ground wave which we encounter much in 
MARS work. Also, a radio filter for those insisting on practicality. 

Bob, wmé6h 

bobh@eworld.com 


